Subject: HPR control vectors and RTP optional segments

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Tue, 5 Dec 95 16:22:49 EST

My previous note contained some errors because I did not research some
info that another person gave me carefully enough.  Please discard it.
Updated material is marked with change bars.  My intent isn't to change
any part of the HPR standard, but simply to explain why some of the CV
numbers are seemingly being reused.

RTP first came to life as part of IBM's Networking Broadband Services
(NBBS) architecture.  We did the NBBS encodings using a different
codepoint space than SNA--they start at x'00'--since we presumed that a
format's use would be very clear in context.

  Later, we created HPR by borrowing pieces of NBBS and grafting them
  onto APPN.  A desire to preserve commonality between HPR and NBBS led
  us to continue using RTP's NBBS encodings.  Those encodings that were
| directly borrowed use the same codepoints and follow the convention
| of aligning fields after variable-length structures on 4-octet
| boundaries, and specifying lengths as octets/4.  The spec is pretty
| specific about which segments and CVs are parsed (length, type)--most
| of them--how the length field is encoded, and when padding is used.

Therefore trace formatters need to interpret the RTP encodings in the
context of RTP.

| As in base APPN, there are a few wrinkles.  Certain CVs that APPN
| parses KL (key, length) for interoperability with subarea are also KL
| for HPR: 61 HPR Caps (in XID) 62 Session Address (in BIND).
|
| As you correctly surmised, CVs x'80' and up are context-sensitive.

In hindsight I admit that we were short-sighted.  Obviously this presents
difficulty not only for trace formatters but it will also require new
chapter(s) in the SNA Formats book.

Marcia Peters